Systems, devices, and methods for managing a payment transaction

ABSTRACT

Disclosed herein is a method for managing a payment transaction wherein a processor receives a transaction information input corresponding to a particular card type. The processor then accesses a BIN table and a rate table to calculate a fee based on the transaction information input and compares the calculated fee with alternate fees corresponding to alternate card types. A card type corresponding to a determined lowest fee between the calculated fee and the alternate fees is then outputted. The processor then completes the payment transaction by accessing transaction information corresponding to a user selected card type.

CROSS REFERENCE

This application claims priority under 35 U.S.C. §119 to U.S. patentapplication Ser. No. 13/443,882, filed on Apr. 10, 2012, the disclosureof which is incorporated herein by reference in its entirety.

BACKGROUND

Traditional card transaction practices include authorization, clearing,settlement and funding actions to complete card transactions betweenseveral entities such as the cardholder, merchant, acquirer, issuer, andcard network. Card transactions include payments made using differenttypes of payment cards such as a credit card, debit card, gift card,etc. The authorization action includes a cardholder presenting a card aspayment to the merchant and the merchant submitting the transaction tothe acquirer. The acquirer verifies the card holder has available fundsfor settlement by passing at least the card number, the transaction typeand the amount to the card network and obtains a transactionauthorization. Settlement or clearing of the transactions is typicallydone by the merchant once per day and in a batch containing all theday's transaction. The settlement is passed to the merchant acquirer.The merchant acquirer subsequently settles the transactions further withthe appropriate card network such as VISA®, MasterCard® or AmericanExpress®, NYCE® etc. Almost all transactions incur an interchange feethat the card network designates per published rates. Interchange feesare collected by the card networks from merchants either on daily ormonthly basis. Card networks then remit these interchange fee to thecard issuing banks. Depending on the card type, transaction type and themerchant type among other factors different interchange fees may beassessed by the card network for the same purchase transaction. Forexample, the card network may charge the merchant an interchange fee of1.85% of the sale price plus $0.10 for a typical credit card rendered,whereas the same merchant may be assessed an interchange fee of 2.4% ofsale price plus $0.10 for a reward credit card for the purchase of thesame good, payment method (i.e. online) and using the same card network(i.e. VISA®).

Further, the same merchant may be charged an even higher rate for abusiness card issued on the same card network and by the same cardissuer for exactly the same transaction. Alternatively, a reward cardmight be charged a higher interchange fee than a non-reward card on thesame network. Debit cards participating in more than one network e.g.STAR® and MasterCard® may be assessed a different interchange feedepending on the network used by the merchant. Therefore, merchants havean incentive to find the least expensive method to process cardtransactions (i.e. process card transactions through the lowest costnetwork) to reduce card processing costs; costs that may add up tomillions of dollars a year.

SUMMARY

Embodiments of the present disclosure provide systems, methods, anddevices for managing payment transactions. Persons of ordinary skill inthe art would recognize that different fees are incurred when acardholder presents different cards to a merchant for processing. Thesefees include an interchange fee, a card network fee, and a cardprocessor fee. The interchange fee is assessed by the card network. Thecard network collects the interchange fee from the merchant's acquireron behalf of the issuer and in turn the merchant acquirer collects thefee from the merchant itself. The card network fee is charged by thecard network such as VISA®, MasterCard®, NYCE® or Star®. The cardprocessor fee is charged by a processor of the card transaction, such asFirst Data, Elavon, Vantiv, etc. Thus, for example, when a VISA® debitcard issued by Chase bank is rendered to a merchant and processed byFirst Data, the interchange fee would be collected by the card networkVISA from the merchant acquirer and paid to Chase bank, the card networkfee would be due to VISA, the processor fee would be due to First Data.All fees collected above are typically paid by the merchant as part ofdoing business and therefore the merchant has much incentive to reducethese fees. In one embodiment, the cost of processing the card paymenttransaction may be the total of the interchange fee, card network fee,and processor fee, as shown by the following equation:

Cost=interchange fee+card network fee+processor fee  (1)

Persons of ordinary skill in the art would understand that in otherembodiments the cost may include a subset or additional fees to thoseshown in the above equation. Further, many debit and credit card issuersoffer various card types with various features that are chosen by theissuers within guidelines provided by the card networks, to meet theneeds of different types of cardholders, and result in differentinterchange rates to the merchants. For example at present a VISA®credit card issuer may offer a Consumer Credit VISA®, Consumer Rewards®or Corporate credit card, each having different features for thecardholders such as extended warranties on purchases or reward points,and each having a different interchange rate. For example, a retailersuch as Staples® selling a $100 toner cartridge for a laser printermight have to pay $3.05 to its acquirer (2.95%+$0.10) when a CorporateCredit card is used to purchase the toner cartridge, whereas when aConsumer Credit card is used to purchase that same toner cartridge, thenit will only cost Staples $1.90 (1.80%+$0.10) in interchange fees due todifferential interchange pricing set at the card network. Typically,interchange and card network fees associated with debit cardtransactions may be lower than fees associated with credit cardtransactions because the perceived risk to the issuer is lowered asfunds availability is verified at the time of authorizations, amongother reasons. Further, most debit card issuers are members of at leasttwo separate card networks. For example, debit card issuer Bank ofAmerica may be member of Visa® as well Star® debit networks andtherefore cards issued by Bank of America may be processed througheither network based on cardholder preference, merchant preference, ordepending on the rules of the networks. That allows the merchant thecapability of routing card transactions to one of those networks forprocessing. Traditionally regional debit networks such as STAR®, NYCE®and Pulse® charge lower interchange fees for processing transactionsthan larger card networks such as VISA® or MasterCard®. Historically,the regional networks were initially developed as ATM networks butwithin the last 20 years they have increased the capabilities of theirnetworks to enable payment acceptance by merchants. For example, theregional networks have developed technologies to accept ATM PINs at thepoint of purchase where the cardholder inputs a PIN on a PIN pad afterbeing prompted to do so at the time of purchase. These transactions arecalled PIN based debit or PIN debit and are relatively secure from frauddue to the nature of PIN based authorization. Similarly, the regionalnetworks began to offer companies that have recurring billing such asutilities, municipality etc. ability to use the regional networks toprocess debit card transactions that are conducted via Internet ortelephone without a PIN. That is, the card is not physically presentedto the merchant at the point of sale and no PIN is inputted to validatethe transaction. Such transactions are called PIN-less debittransactions where a PIN is not entered during the payment transaction.Recently virtual PIN pads have been offered for securely capturing a PINfor card payment transactions conducted via Internet, where the card isnot rendered at a point of sale. Moreover, the recently passed Durbinamendment part of The Dodd-Frank Wall Street Reform and ConsumerProtection Act (Pub. L. 111-203, H.R. 4173), requires all debit cardsissued by US financial institutions to support processing through atleast two unrelated debit card networks. In addition, the new Durbinamendment regulates the interchange fee for debit card issuing bankswith assets greater than $10 billion.

In another embodiment, some merchants such as utility companies charge aconvenience fee to process or handle cards for payment transactions.Such a convenience fee may include a profit in addition to the costincurred by the merchant, which includes the interchange fee, cardnetwork fee, and processor fee as shown in the following equation.

Convenience fee=cost+profit  (2)

The convenience fee may be calculated by different algorithms known inthe art and include different variables such as expected profit, priceelasticity, volume of card payment transactions and other economic andnon-economic variables. Alternative embodiments include that thedifferent algorithms calculate dynamically the convenience fee based ona discount from a static convenience fee. The static convenience fee maybe determined by the factors mentioned above.

Embodiments of the present disclosure include a method for managing apayment transaction. The method includes receiving at a computer server,a first transaction information including a first rendered cardinformation payment amount, and merchant type. A further step in themethod may include accessing BIN and rate information from a table,using the computer server, based on the first transaction informationstored in a computer. In addition, the method may include calculating,using the computer server, a first cost based on the BIN and rateinformation and calculating a first convenience fee for the firstrendered card. Also, the method may include determining a firstsuggested card type by the computer server based on an algorithmimplemented by software such that the first suggested card type has alower cost than the first cost and a lower convenience fee than thefirst convenience fee and may also provide the first suggested card typeto a user.

Moreover, the method may include calculating a first suggestedconvenience fee for the first suggested card type as well as providingthe first suggested convenience fee to the user. Further, the firstrendered card information is selected from the group consisting of a BINor a card number. In addition, the table may have BIN and rateinformation is stored in one or more storage devices. Also, the methodmay include storing a subset of the first transaction information by thecomputer server.

Further, the method may include receiving, at a computer server, asecond transaction information including a second rendered cardinformation, accessing BIN and rate information from the table, usingthe computer server, based on the second transaction information as wellas calculating, using the computer server, a second cost based on theBIN and rate table information and a second convenience fee for thesecond rendered card. In addition, the method may include determining asecond suggested card type by the computer server based on an algorithmimplemented by software such that the second suggested card type has alower cost than the first cost and the second cost, and the secondsuggested card type has a lower convenience fee than the firstconvenience fee and the second convenience fee as well as providing thesecond suggested card type to the user.

Moreover, the method may include storing a subset of the firsttransaction information by the computer server as well as storing asubset of the second transaction information by the computer server.Further, the method may include accessing the first transactioninformation, and processing the first transaction information on a cardnetwork. In addition, the method may include receiving instructions fromthe user to select one of the rendered cards for the transaction,accessing the transaction information corresponding to the selectedrendered card, and processing the transaction information on a cardnetwork. Persons of ordinary skill in the art would understand from thedisclosed embodiments that a user may render multiple cards (e.g. morethan two) and the systems and methods. Also, the method may includedetermining that a rendered card is on a blocking list stored by thecomputer server further blocking the processing of the rendered card.

Further, transaction information may be selected from the groupconsisting of payment information, payment amount, transaction type,merchant information, merchant type, merchant category, cardinformation, card type, the card number, BIN, card expiration date,cardholder address, PIN, security code, asset size of the card issuer,and card networks of which the card issuer is a member. In addition,each of the suggested card type can be selected from the groupconsisting of a credit card, debit card, prepaid card, charge card,reward credit card, corporate credit card, rewards debit card, retailercredit card, and gift card.

Embodiments of the disclosure include a system for managing a paymenttransaction. The system includes one or more processors, one or morestorage devices, each coupled to the one or more processors and one ormore communication interfaces coupled to the one or more processors andcapable of being coupled to one or more communication networks. Furthercomponents may include one or more software applications residing on thesystem, implemented by the one or more processors. The one of moresoftware applications may include a processing engine that receives afirst transaction information including a first rendered cardinformation, payment amount, and merchant type. Other softwareapplications may be one or more look up engines that (i) access BIN andrate information from a table based on the first transaction informationstored in a computer; and (ii) pass the BIN and rate table informationto the processing engine. In addition, the processing engine further:(i) calculates a first cost based on the BIN and rate information andcalculates a first convenience fee for the first rendered card; (ii)determines a first suggested card type based on an algorithm implementedby software such that the first suggested card type has a lower costthan the first cost and a lower convenience fee than the firstconvenience fee; (iii) provides the first suggested card type to a user.

Moreover, the processing engine calculates a first suggested conveniencefee for the first suggested card type as well as provides firstsuggested convenience fee to the user. Further, the first rendered cardinformation is selected from a group consisting of a BIN or a cardnumber. In addition, the table having BIN and rate information is storedin one or more storage devices. Also, the processing engine stores asubset of the first transaction information in the one or more storagedevices.

In addition, the processing engine receives a second transactioninformation including a second rendered card information, the one ormore look-up engines access BIN and rate information from the tablebased on the second transaction information, and the processing enginefurther calculates a second cost based on the BIN and rate tableinformation and a second convenience fee for the second rendered card.Moreover, the processing engine (i) determines a second suggested cardtype based on an algorithm implemented by software such that the secondsuggested card type has a lower cost than the first cost and the secondcost, and the second suggested card type has a lower convenience feethan the first convenience fee and the second convenience fee; and (ii)provides the second suggested card type to the user.

Also, the processing engine stores a subset of the first transactioninformation in the one or more storage devices as well as stores asubset of the second transaction information in the one or more storagedevices. Further, the computer server accesses the first transactioninformation, and processes the first transaction information on a cardnetwork. In addition, the computer server may receive instructions fromthe user to select one of the rendered cards for the transaction, accessthe transaction information corresponding to the selected rendered card,and process the transaction information on a card network. Persons ofordinary skill in the art would understand from the disclosedembodiments that a user may render multiple cards (e.g. more than two)and the systems and methods. Moreover, the processing engine determiningthat a rendered card is on a blocking list stored by the computer serverfurther blocking the processing of the rendered card.

Further, the transaction information is selected from the groupconsisting of payment information, payment amount, transaction type,merchant information, merchant type, merchant category, cardinformation, card type, the card number, BIN, card expiration date,cardholder address, PIN, security code, asset size of the card issuer,and card networks of which the card issuer is a member. In addition,each suggested card type can be selected from the group consisting of acredit card, debit card, prepaid card, charge card, reward credit card,corporate credit card, rewards debit card, retailer credit card, andgift card.

Embodiments of the present disclosure include a method for managing apayment transaction. The method includes receiving, at a computerserver, a first transaction information including a first rendered cardinformation, payment amount, and merchant type, accessing BIN and rateinformation from a table, using the computer server, based on the firsttransaction information stored in a computer as well as calculating,using the computer server, a first cost based on the BIN and rateinformation and calculating a first incentive for the first renderedcard. The method may also include determining a first suggested cardtype by the computer server based on an algorithm implemented bysoftware such that the first suggested card type has a lower cost thanthe first cost and a larger incentive than the first incentive as wellas providing the first suggested card type to the user.

Moreover, the method may include calculating a first suggested cost anda first suggested incentive for the first suggested card type as well asproviding the first suggested incentive to the user. The first renderedcard information is selected from the group consisting of a BIN or acard number. Further, the table having BIN and rate information isstored in one or more storage devices. The method may include storing asubset of the first transaction information by the computer server.

In addition, the method may include receiving, at a computer server, asecond transaction information including a second rendered cardinformation, accessing BIN and rate information from the table, usingthe computer server, based on the second transaction information as wellas calculating, using the computer server, a second cost based on theBIN and rate table information and a second incentive for the secondrendered card. Moreover, the method may include determining a secondsuggested card type by the computer server based on an algorithmimplemented by software such that the second suggested card type has alower cost than the first cost and the second cost and the secondsuggested card type has a larger incentive than the first incentive andthe second incentive as well as providing the second suggested card typeto the user.

Further, the method may include storing a subset of the firsttransaction information by the computer server as well as storing asubset of the second transaction information by the computer server. Inaddition, the method may include accessing the first transactioninformation, and processing the first transaction information on a cardnetwork. Moreover, the method may include receiving instructions fromthe user to select one of the rendered cards for the transaction,accessing the transaction information corresponding to the selectedrendered card, and processing the transaction information on a cardnetwork. Persons of ordinary skill in the art would understand from thedisclosed embodiments that a user may render multiple cards (e.g. morethan two) and the systems and methods. Further, the method may includedetermining that a rendered card is on a blocking list stored by thecomputer server further blocking the processing of the rendered card.

Also, transaction information is selected from the group consisting ofpayment information, payment amount, transaction type, merchantinformation, merchant type and merchant category, and card information,card type, the card number, BIN, card expiration date, cardholderaddress, PIN, security code, asset size of the card issuer, and cardnetworks of which the card issuer is a member. Further, each suggestedcard type can be selected from the group consisting of a credit card,debit card, prepaid card, charge card, reward credit card, corporatecredit card, rewards debit card, retailer credit card, and gift card. Inaddition, each incentive can be selected from the group consisting ofgoods, coupons, charity, points, or third party incentives.

Embodiments of the disclosure include a system for managing a paymenttransaction. The system includes one or more processors, one or morestorage devices, each coupled to the one or more processors, one or morecommunication interfaces coupled to the one or more processors andcapable of being coupled to one or more communication networks. Thesystem includes one or more software applications residing on thedevice, implemented by the one or more processors. The one of moresoftware applications include a processing engine that receives a firsttransaction information including a first rendered card information,payment amount, and merchant type as well as one or more look up enginesthat (i) accesses BIN and rate information from a table based on thefirst transaction information stored in a computer; and (ii) passes theBIN and rate table information to the processing engine. Further, theprocessing engine further: (i) calculates a first cost based on the BINand rate information and calculates a first incentive for the firstrendered card; (ii) determines a first suggested card type based on analgorithm implemented by software such that the first suggested cardtype has a lower cost than the first cost and a larger incentive thanthe first incentive; (iii) provides the first suggested card type to auser. In addition, the processing engine calculates a first suggestedcost and a first suggested incentive for the first suggested card typeas well as the processing engine provides the first suggested incentiveto the user. The first rendered card information is selected from agroup consisting of a BIN or a card number. In addition, the tablehaving BIN and rate information is stored in one or more storagedevices. Also, the processing engine stores a subset of the firsttransaction information in the one or more storage devices. In addition,the processing engine receives a second transaction informationincluding a second rendered card information, the one or more look-upengines access BIN and rate information from the table based on thesecond transaction information as well as the processing engine furthercalculates a second cost based on the BIN and rate table information anda second incentive for the second rendered card. Moreover, theprocessing engine (i) determines a second suggested card type based onan algorithm implemented by software such that the second suggested cardtype has a lower cost than the first cost and the second cost and thesecond suggested card type has a larger incentive than the firstincentive and the second incentive; and (iii) provides the secondsuggested card type to the user.

In addition, the processing engine stores a subset of the firsttransaction information in the one or more storage devices as well asstores a subset of the second transaction information in the one or morestorage devices. The computer server accesses the first transactioninformation, and processes the first transaction information on a cardnetwork. Further, the computer server receives instructions from theuser to select one of the rendered cards for the transaction, accessesthe transaction information corresponding to the selected rendered card,and processes the transaction information on a card network. Persons ofordinary skill in the art would understand from the disclosedembodiments that a user may render multiple cards (e.g. more than two)and the systems and methods. The processing engine determines that arendered card is on a blocking list stored by the computer serverfurther blocking the processing of the rendered card.

Transaction information is selected from the group consisting of paymentinformation, payment amount, the transaction type, merchant information,merchant type, merchant category, and card information, card type, thecard number, BIN, card expiration date, cardholder address, PIN,security code, asset size of the card issuer, and card networks of whichthe card issuer is a member. Each suggested card type can be selectedfrom the group consisting of a credit card, debit card, prepaid card,charge card, reward credit card, corporate credit card, rewards debitcard, retailer credit card, and gift card. Moreover, each incentive canbe selected from the group consisting of goods, coupons, charity,points, or third party incentives.

The foregoing summary is illustrative only and is not intended to be inany way limiting. In addition to the illustrative aspects, embodiments,and features described above, further aspects, embodiments, and featureswill become apparent by reference to the drawings and the followingdetailed description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute partof this specification, illustrate embodiments of the invention andtogether with the description serve to explain the principles of thepresent disclosure. The embodiments illustrated herein are presentlypreferred, it being understood, however, that the invention is notlimited to the precise arrangements and instrumentalities shown,wherein:

FIGS. 1A-3B are exemplary functional block diagrams of systems formanaging payment transactions in accordance with embodiments of thepresent disclosure;

FIG. 4 is an exemplary device for managing a payment transaction inaccordance with embodiments of the present disclosure;

FIG. 5 is another exemplary device for managing a payment transaction inaccordance with embodiments of the present disclosure; and

FIG. 6 is an exemplary flowchart of an example method for managingpayment transactions in accordance with embodiments of the presentdisclosure.

DESCRIPTION OF EXEMPLARY EMBODIMENTS

In the following detailed description, reference is made to theaccompanying drawings, which form a part hereof. In the drawings,similar symbols typically identify similar components, unless contextdictates otherwise. The illustrative embodiments described in thedetailed description, drawings, and claims are not meant to be limiting.Other embodiments may be utilized, and other changes may be made,without departing from the spirit or scope of the subject matterpresented herein. It will be readily understood that the aspects of thepresent disclosure, as generally described herein, and illustrated inthe Figures, can be arranged, substituted, combined, separated, anddesigned in a wide variety of difference configurations, all of whichare explicitly contemplated herein. Further, in the followingdescription, numerous details are set forth to further describe andexplain one or more embodiments. These details include systemconfigurations, block module diagrams, flowcharts (including transactiondiagrams), and accompanying written description. While these details arehelpful to explain one or more embodiments of the disclosure, thoseskilled in the art will understand that these specific details are notrequired in order to practice the embodiments.

With the Durbin Amendment recently passed by Congress, debit interchangefees were significantly reduced for financial institutions with morethan $10 Billion in assets (regulated). Further, issuers were obliged toenable their cards to be issued and processed by at least twounaffiliated debit networks such as Interlink and Star®; or Star® andNYCE®, etc. This regulation enables merchants to competitively routedebit transactions to the card network with the lowest fee to processits transactions. Thus, merchants may be able to provide lowerconvenience fees as well as incentives, and discounts to customers whenthey use a card with the lowest cost and hence benefit the merchant.Further, other factors affect the fees associated with a debit or creditcard transaction thereby lowering the cost. Some factors may include,but are not limited to, card type (e.g. credit, debit, prepaid,business, reward etc.), size of financial institution that issued thecard, network used to process payment, data captured when payment isrendered (e.g., cardholder address, PIN, etc.), type of merchant(utilities, car rental companies, etc.), and type of transaction (e.g.in person, single payment, recurring payment, Internet payment, etc.).

The factors adjust the fees associated with the credit card or debitcard processing in different ways. For example, generally, fees forprocessing credit cards in a given card network are higher than fees forprocessing debit cards because of lower perceived risk of fraud to theissuers for debit cards. Based on the new Durbin amendment a debit cardissued by a large financial institution, in most circumstances, has alower interchange rate than a debit card issued by a small financialinstitution. A further factor in determining credit or debit cardprocessing fees may be the type of network processing the card. The cardtype, size of financial institution issuing the card, and card networkmay be found by comparing the first several digits of the rendered cardnumber with a Bank Identification Number (BIN) table.

Additional factors that affect credit or debit card processing cost mayinclude the data captured when payment is rendered, the type ofmerchant, and the type of transaction. In most cases, the more datacaptured when payment is rendered (e.g. card expiration date, cardholderaddress, PIN, etc.) the lower the fees thereby reducing the cost. Thereason for the lower cost is because the more cardholder information isgathered by the merchant, the less likely it is that a fraudulenttransaction may occur. Another factor affecting the cost of a cardtransaction may be the type of merchant. For example, merchants who takepayments from customers with whom they have an ongoing relationship(such as utilities, insurance companies, or cable TV providers) arecharged lower interchange fees in many circumstances than merchants whotake payments from customers that they do not know, or merchants whotake payments for services for which the full price is not known at thetime of the purchase (such as e-commerce transactions). The reason beingis that there is more risk of fraud with a one-time payment transactionthan with recurring payment transactions. In addition, the type oftransaction, such as whether it is an in-person transaction, singlepayment, recurring payment, phone payment, or Internet payment wouldaffect the card processing cost. Such interchange fees associated withdata capture, merchant type, and transaction type can be found in one ormore rate tables published by card networks.

An illustrative summary of some but all factors that may affectsinterchange fees, and are used in cost determination is shown in Table 1below.

TABLE 1 Factor How does it affect Cost How can fee be determined Thetype of card that is used. Fees for processing credit cards are Bylooking up a subset Such as a Credit Card, Debit higher than fees forprocessing of (typically 6) digits of Card, combined Credit/Debit debitcards. the card number in a Card, ATM Card, or Prepaid BIN Table, thesystem Card. can determine the card type. The size of the financialDebit cards issued by large By looking up a subset institution thatissued the financial institutions have lower of (typically 6) digits ofcard. fees than debit cards issued by a debit card number in a smallfinancial institutions. BIN Table the system can determine the size ofthe financial institution. The network that is used to Differentnetworks have different By looking up a subset process the payment. Manyfees. of (typically 6) digits of cards allow processing via a debit cardnumber in a more than one network. BIN Table the system can determinewhat networks can be used to process a payment from the card. The datathat is captured The more data is captured, the Networks publish whenthe payment is taken. lower the cost. fee/rate tables that show (e.g.card expiration date, what data is required to cardholder address, PIN).qualify for lower fees. The type of merchant. Merchants who takepayments Each Merchant that is from customers with whom they registeredto receive have an ongoing relationship (such payments has a asutilities, insurance companies, Merchant Category or cable TV providers)are charged Code or an Industry lower fees that Merchants whoClassification code. take payments from customers that Networks publishfee they do not know, or merchants tables that show which who takepayments for services for merchants qualify for which the full price isnot known at what fees. the time of the purchase (such as car rentalcompanies). The type of transaction (e.g. Networks publish in person,single payment, fee/rate tables that show recurring payment, phone whichtransaction types payment, internet payment). qualify for which fees.

The exact factors that determine the cost of processing a payment fromthe card, the number of networks that are available to process apayment, and the structure of the BIN and rate tables published by eachnetwork are subject to change, due to regulation, card network pricing,competitive pressures and the introduction of new types of merchants.Other embodiments of the present disclosure fulfill a unique role byperforming lookups in the most recent BIN tables and rate tables inreal-time to determine a cost of the transaction before suggesting aconvenience fee or incentive for each card payment transactionappropriate to that specific transaction.

FIGS. 1A-3B are exemplary functional block diagrams of systems formanaging card payment transactions in accordance with embodiments of thepresent disclosure. Referring to FIG. 1A, the exemplary functional blockdiagram includes a client computing device 202, a look up engine 204, aBIN table 206, a processing engine 210 (e.g., a processor), and a ratetable 212. A client computing device 202 may be a tablet, notebook,laptop, or desktop computer as well as a landline phone, mobile phone,smartphone or any other client computing device such as a point-of-saleterminal. Embodiments of the disclosure may have the look-up engine 204and the processing engine 210 on a server (e.g. merchant server,Facilitator server, etc.) and the client computing device may have a webbrowser as software or be a voice or CSR terminal. The server mayalternatively be coupled to the client computing device through anapplication programming interface (API). In such a case the serverreceives card or transaction information from the client computingdevice through an API. The rate table may be multiple tables and but inthe embodiment shown in the pending disclosure the rate table is shownas a singular table rather than a plurality of tables.

In the embodiment shown in FIG. 1, the look up engine 204, a BIN table206, a processing engine 210, and a rate table 212 are on a server 220such as a Facilitator (e.g. third party or vendor) server or a merchantserver among others (e.g. a financial institution server). Persons ofordinary skill in the art would understand that further embodiments maynot only include one server but a distributed system of servers thateach implement a subset of the software applications discussed in thepending disclosure. A card holder may initiate a payment transaction byrendering a payment card (e.g. credit card, debit card, rewards card,prepaid debit card, gift card, etc.) using various means that include asoftware application on the client computing device 202 such as webbrowser. The look up software engine 204 may be implemented by aFacilitator server that receives the card information (e.g. card numberor BIN number) and other transaction information (e.g. merchantinformation) to access information from the BIN table 206 and the ratetable 212. Further, the look up software engine 204 may then process theinformation to determine the associated cost of the transaction(interchange fee, card network fee, processor fee among others) for thecard rendered in the payment transaction. Thus, when the card is acredit card, then the look up table 204 may access a rate table 212 todetermine the interchange fee and any other fee that may be associatedwith the payment transaction. Further, when the card is a debit card,the look up engine 204 may access a BIN table 206 to determine the costassociated with the debit card (or any other fee associated with thepayment transaction). The BIN table 206 and rate tables 212 may bestored in a database or other storage device associated with the server220. The look up engine 204 may then forward the determined orcalculated cost (including the interchange fee, network fee, andprocessor fee) to the processing engine 210. Further, the processingengine 210 may implement one or more software applications incorporatingalgorithms to determine a convenience fee for the rendered card. Asmentioned previously, the convenience fee is the fee charged to theconsumer making the payment transaction for processing that paymenttransaction and is typically the sum of the cost of payment transactionand the profit associated with a payment transaction. The algorithms mayincorporate other economic factors such as price elasticity, volume ofcard transactions, customer demand, day of the month, and other knownfactors in the art relevant to the transaction, implemented by themerchant server, Facilitator server and other servers in order tocalculate the appropriate convenience fee for a transaction. Alternativeembodiments include that the different algorithms calculate dynamicallythe convenience fee based on a discount from a static convenience fee.The static convenience fee may be determined by the factors mentionedabove. For example a static convenience fee of $10 may be assessed anddisclosed for all card transactions for a particular merchant. However,based on the implemented algorithm, when a reward credit card isrendered the system may suggest two alternate cards: (1) a conventionalcredit card with a discount of $2 from the static convenience fee,resulting an $8 convenience fee to the consumer/user; or (2) a debitcard with a $6 discount from the static convenience fee resulting in aconvenience fee of $4 to the consumer/user. In a further embodiment, thesystem may have more than one static convenience fee calculated andstored in the system based on the first card rendered. For example, whena reward credit card is rendered first a static convenience fee iscalculated (e.g. $10) associated with that rewards credit card based onthe implemented algorithm. All discounts henceforth for alternate orrendered cards will be calculated based on this ($10) convenience fee.Alternatively when convention credit card is rendered first a staticconvenience fee may be calculated (e.g. $7) associated with thatconventional credit card based on the implemented algorithm. Alldiscounts henceforth for alternate or rendered cards will be calculatedbased on the ($7) convenience fee.

In certain circumstance a surcharge rather than a discount may beassessed on a static convenience fee. This may apply when a card withhigher interchange fee such as corporate cards is presented as well asfor other reasons. The discount and surcharge calculation may beimplemented to address card network regulation.

Further, the exemplary system 200 shown in FIGS. 1A-C may calculate aconvenience fee for a card rendered by the customer such as a rewardscredit card, for example, and then calculate a convenience fee (e.g.,alternate convenience fee) for different types of cards (e.g., alternatecard types) such as a conventional credit card or a debit card. The costfor processing a debit card transaction is typically lower than for arewards credit card or conventional credit card. Thus, the exemplarysystem 200 may suggest to the customer to render a conventional creditcard or a debit card instead of a rewards credit card so has to incur alower convenience fee. Further, the merchant may have access to morethan one card networks to process a card for a payment transaction.Thus, the exemplary system 200 may calculate a cost of processing adebit card on the two different card networks and select the lower costautomatically and use this cost in calculating the convenience feeassociated with the debit card. In other words, the exemplary system 200may calculate alternate costs used to determined a lowest cost forcalculating the convenience fee associated with the debit card.

For example, a customer may pay utility bill on a utility company's(merchant) website. Thus, the customer may use the web browser on theclient computing device 202 to access the merchant website. Further, thecustomer may provide a rewards credit card number to the merchantwebsite through the web browser that is received by the processingengine 210 of the Facilitator server 202. The processing engine 210 mayinstruct the look-up engine 204 to access information from at least therate table 212 and BIN table for a credit card network and forward suchinformation to the processing engine 210. Further, the processing engine210 may determine the cost associated with rendered rewards credit cardas well as a convenience fee 1 214 to offer the customer as shown inFIG. 1A. Further, the rewards credit card number or its BIN and otherrelevant transaction information are stored by the Facilitator server202. In addition, the exemplary system 200 may suggest two otherconvenience fees (216 and 218) each associated with other cards (e.g.conventional credit card, and regulated debit card, etc.) that yield alower convenience fee. The description of FIGS. 1B and 1C discuss thecalculation of the other two convenience fees (216 and 218).

Referring to FIG. 1B, after determining convenience fee 1 (214)associated with a rendered rewards card, the processing engine 210,based on an algorithm, may instruct the look-up engine 204 to accessinformation from the rate table 212 and BIN table for another card(e.g., alternate card types) that the processing engine 210deterministically expects to have a lower processing cost per algorithmsuch as a conventional credit card. The algorithm may take into accountsituations when a high cost card (e.g. rewards credit card) is renderedto calculate the convenience fee of lower cost cards such asconventional credit cards or debit cards.

Consequently, the processing engine 210 may calculate transaction costand then a convenience fee 2 (216) associated with processing aconventional credit card for the same purchase. Typically, the costassociated in processing a conventional credit card is lower than thecost of processing a rewards credit card. Thus, the convenience fee 2(216) for a conventional credit card may be lower than the conveniencefee 1 (214) associated with the rendered rewards credit card. In certainembodiments, the exemplary system 200 may suggest a convenience fee 2(216) to the customer through an API, a client computing device's webbrowser, or other means known in the art, as a less expensive alternateto convenience fee 1 (214). In such scenario system 200 may suggest theuser to render a conventional credit card instead of a rewards creditcard when they are in possession of such a conventional card to pay alower fee of $4.95 rather than $7.95 for rewards credit card suggestinga saving of $3.

However, in some embodiments, a customer may not have or may not chooseto render a suggested card after receiving the suggestions to use adifferent card that may yield a lower convenience fee 2 (216). Thus, thecustomer may render another, different type of card. The processingengine 210 may store second rendered card information and calculate thecard's corresponding convenience fee. Further, the processing engine 210may also calculate alternate convenience fees. For example, theprocessing engine 210, based on the algorithm may determine that when acustomer rendered two different rewards credit cards that it may thencalculate the rewards credit card having the lowest convenience fee andsuggest such a rewards credit card as an alternate to the customer.Further, the processing engine 210 may suggest the previously suggestedcard having a lower convenience fee. The customer may then render athird card or select one of the previously rendered cards (informationfor which has been previously stored by the processing engine 210 in astorage device) to the process a current transaction.

In another embodiment, a customer may render transaction informationinput corresponding to a plurality of “card” types which may be storedby the processor. When a customer (e.g., a user) chooses to make apayment transaction, the customer may select one of the stored card typefor the transaction process. In response to receiving a user selectioncorresponding to one of the stored plurality of a card type, theprocessor may be configured to access the BIN and rate tables.Additionally, the processor may be configured to calculate theconvenience fee and the cost based on the transaction informationcorresponding to the selected stored card type. The processor may alsobe configured to calculate alternate convenience fees and alternatecosts corresponding to alternate card types using at least the BIN andrate tables. The processor may then compare the calculated conveniencefee and cost corresponding to the selected stored card type with thealternate convenience fees and alternate costs to determine whether theselected stored card type has a lower convenience fee and cost than thealternate card types. In response to determining that the selectedstored card type has the lower convenience fee and cost, the processormay be configured to complete the payment transaction using the selectedstored card type.

Alternatively, the processor may be configured to calculate aconvenience fee and a cost corresponding to the transaction informationinput of each stored card type. Furthermore, the processor may completethe payment transaction using the stored card type having the lowestconvenience fee and cost as calculated using the BIN and rate tables.The processor may also be configured to receive transaction inputinformation corresponding to a plurality of card types which theprocessor may directly access from a server. Alternatively, in responseto determining that the comparison of the calculated convenience fee andthe alternate convenience fees is above a predetermined threshold, theprocessor may be configured to output a fixed convenience fee and afixed costs based on the comparison.

Referring to FIG. 1C, the processing engine 210 may determine the costand convenience fee 3 (218) associated with a debit card. The look upengine 204 may access information pertaining to the payment transactionand calculate the cost of processing the payment transaction with adebit card rather than a rewards or conventional credit. The processingengine 210 calculates a convenience fee for processing the debit cardfor one or more debit card networks and selects the lower conveniencefee (see convenience fee 3 218 in FIG. 1C) to be associated with a debitcard. Such a convenience 3 (218) may be suggested to the customerthrough the client computing device web browser and other meansdescribed above or known in the art in addition to convenience 2 (216)associated with a conventional card and convenience 1 (214) associatedwith the rendered rewards credit card. Thus, the customer may select torender a conventional credit or a debit card, when either one isavailable, instead of the rewards credit card.

The calculation and suggestion of three convenience fees in FIGS. 1A-1Cis exemplary and by no means limiting. Persons of ordinary skill in theart understand that the number of convenience fees calculated, and theirassociated cards suggested, may not be limited. Also, the examples andembodiments described in the pending disclosure may be combined,separated and rearranged as would be understood by those persons withordinary skill in the art.

In another embodiment, prior to offering the various differentconvenience fees (214, 216, 218), the processing engine 210 may cause aquery to the customer via the web browser, API, or other means known inthe art to the client computing device 202 to request more informationregarding the transaction such as PIN, card holder address, CVV code,etc. Based on the additional transaction information, the look-up engine204 may access different information from at least the rate table 212and BIN table 206. Such information may be passed to the processingengine 210 to determine a different cost and hence convenience fee (214,216, and 218) for processing a customer's rewards credit card,conventional credit card, and/or debit card.

Additional embodiments may include the processing engine 210 determiningthe cost and convenience fee for a customer to render an automatedclearing house (ACH) payment for a transaction. Prior to determiningsuch ACH cost and associated convenience fee, the processing engine 210may query the customer for additional information. Further suchadditional information may assist the processing engine 210 to determinethe ACH cost and convenience fee. If the convenience fee is lower thanthe convenience fee associated with the rendered card, the processingengine may suggest ACH as an alternate method of payment.

It is possible that the system 200 may not suggest to render analternate card to customer because savings due to the cost associatedwith any such alternate card is too small as compared to the initiallyrendered card (e.g. debit card) or other reasons based on algorithmsstored in the system 200. In such an embodiment, the savings are notmaterial in view of capturing the transaction in an efficient mannerbased on an algorithm and information stored by the merchant server orFacilitator server by the processing Engine 210. For example, algorithmscould be configured such that when a convenience fee for a possiblealternate card is determined to be less than 50 cents below the feecalculated for the rendered card, then the algorithm implemented by theprocessing engine 210 may prevent the processing engine 210 fromsuggesting such an alternate card to the customer.

Alternative embodiments may include that the system 200 in general, andprocessing engine 210 in particular, determine convenience fees fordifferent types of cards (e.g. rewards credit card, conventional creditcard, debit card) and suggest them to the customer after the customer isready to pay for goods and services (such as in an e-commercetransaction) but before the customer renders any card for payment.

Other embodiments may include that the look up engine and/or processingengine may be implemented by the client computing device 202 (e.g. whenthe client computing device 202 is a POS terminal). Further, the BINtable and rate table are accessible by the client computer device 202 orby the Facilitator server 220 from a remote server or database.

In an alternate embodiment, the processing engine 210 may access ablocking list. Such a list may have a set of BINs that the system 200may not accept for various reasons. For example, the cost for processingcards that belong to certain BINs may be high or for other reasons.Thus, when a card is rendered with such a blocked BIN, the processingengine 210 may provide feedback to the customer that the card cannot beprocesses for various reasons and suggest alternate cards for them torender with low convenience fees.

Referring to FIG. 2A, the exemplary functional block diagram includes aclient computing device 302, a processing engine 303, a BIN look upengine 304, a BIN table 306, rate look up engine 308, a rate table 310,an incentive engine 314, and an incentive table 312. A client computingdevice 302 may be a tablet, notebook, laptop, or desktop computer aswell as a landline phone, mobile phone, smartphone or any other clientcomputing device such as a point-of-sale terminal. Alternativeembodiments may have the look-up engine 304 and the processing engine310 on a server (e.g. merchant server, Facilitator server, etc.) and theclient computing device may have a web browser as software or be a voiceor CSR terminal. The embodiment shown in FIG. 2A, the processing engine303, a BIN look up engine 304, a BIN table 306, rate look up engine 308,a rate table 310, an incentive engine 314, and an incentive table 312are on a Facilitator server.

A card holder may initiate a payment transaction with a credit card ordebit card using a software application on the client computing device302. The processing engine 303 may be implemented by Facilitator server320 that receives the transaction information (e.g. card number) fromthe client computing device through a web browser, API or other meansknown in the art and may cause the BIN look up software engine 304 andthe rate look up engine 308 to access at least the BIN table and ratetable information. Further, the processing engine 303 may process thetransaction information to determine the associated cost for processingthe rendered card for the payment transaction. Note, persons of ordinaryskill in the art would understand that comparing the embodiment shown inFIGS. 2A-B with the embodiment shown in FIGS. 1A-1C, the functionalityincorporated in look up engine 204 in FIGS. 1A-1C, may be split betweenthe BIN look up engine 304 and the rate lookup engine 308 in FIGS.2A-2B.

Moreover the BIN look up engine 304 may access a BIN table 306 and ratelook up engine 308 may access a rate table 310 to determine the feesassociated for the a card that may include the interchange fee, cardnetwork fee, and processor fee or any other fee that may be associatedwith the transaction. For example, a customer may access a utilitycompany website such as a the website of a cellular phone service usinga web browser, API, or other means known in the art through the clientcomputing device 302. The customer may render a conventional card numberto pay a cellular phone bill. The processing engine 303 receives therendered conventional credit card number and transaction informationthen passes the rendered card number to BIN look-up engine 304 and therate look-up engine 308. Further, the BIN look-up engine 304 and therate look-up engine 308 access BIN and rate information from the BINtable 306 and rate table 310, respectively. Such BIN table and ratetable information which may include the interchange fee, card networkfee, processor fee or any other applicable fee may be forwarded to theincentive engine 314. The BIN table 306 and rate table 310 may be storedin a database or other storage device associated with the Facilitatorserver 320. In addition, the incentive engine 314 may calculate the costof processing the rendered conventional credit card based on such BINand rate table information. Also, using different algorithms based onprice elasticity, volume of card transactions, customer demand,recurring nature of the transaction or other economic factors, theincentive engine 314 may determine an incentive 1 (316) corresponding tothe rendered credit conventional card. Such incentive 1 (316) may alsobe listed and stored in the incentive table 312 to be used in futurepayment transactions. In addition, the processing engine 303 and/or theincentive engine 314 may determine an incentive 2 (318) associated witha different card (e.g. debit card) that may be more attractive to thecustomer and having a lower cost to the merchant. In other words, theprocessing engine 303 may calculate alternate incentives correspondingto alternate card types. Such an alternate card may be suggested tocustomer through a client computing device web browser, API, or otherknown means in the art.

Referring to FIG. 2B, an algorithm executed by processing engine 303 maytake into account situations when a high cost card (e.g. rewards creditcard) is rendered to calculate the cost of lower cost cards such asconventional credit cards or debit cards to provide a better incentive.Consequently, the processing engine 303 causes the BIN look up engine304 and rate look up engine 308 to access a at least a BIN table 306 andrate table 310, respectively, to determine BIN and rate informationincluding the fees (e.g. interchange fee, card network fee, processorfee) associated in processing the debit card. Further, due to therequirements of the Durbin legislation, the BIN and rate information mayinclude fees for at least two different debit card processing networks.In addition, the BIN and rate information is forwarded to the incentiveengine 314 which determines the cost for processing the debit card oneach network (i.e. PIN-less debit vs. regular debit). After determiningthe lower cost, the incentive engine determines an incentive 2 (318)using different algorithms based on price elasticity, volume of cardtransactions, customer demand, recurring nature of the transaction orother economic factors. Typically, the cost associated with processing adebit card is lower than processing a conventional credit card. Thus,the incentive engine 314 and Facilitator server 320 may suggest to thecustomer to render a debit card corresponding to incentive 2 (318)instead of the conventional credit card corresponding to incentive 1(316). Hence, incentive 2 (318) may be more attractive (i.e. increased)than incentive 1 (316) to entice a customer to render a debit cardinstead of a conventional credit card. For example, incentive 1 (316)may allow a customer to download 10 free ringtones from the cellularservice provider's website. Alternatively, incentive 2 (318) may allow acustomer to download 25 free ringtones. Other incentives in otherembodiments may include $2 off your utility bill or $10 coupon on nextpurchase from merchant.

Alternatively, the processor may be configured to compare a calculatedcost based on the transaction information input using at least the BINand rate tables and compare the calculated costs and alternate costscorresponding to alternate card types using the BIN and rate tables. Inresponse to determining that the comparison of the calculatedconvenience fee and the alternate convenience fees is above apredetermined threshold, the processor may be configured to output afixed convenience fee and a fixed costs based on the comparison.

In alternate embodiments, prior to offering two different incentives(316 and 318), the processing engine 303 may cause a query to the uservia the web browser of the client computing device 302 to request moreinformation regarding the transaction such as PIN, card holder address,CVV code, etc. Such additional card information may be passed to the BINlook-up engine 304 and rate look-up engine to access different BIN andrate information that is provided to the incentive engine 314. Further,the incentive engine 314 may determine more attractive incentives (316and 318) to suggest to the customer because, typically, the cost ofprocessing cards is lower when more rendered information is collectedfrom the customer.

Additional embodiments may include the incentive engine 314 determiningthe cost and incentive for a customer to render an automated clearinghouse (ACH) payment for a transaction. Prior determining such ACH costand associated incentive, the processing engine 303/incentive engine 314may query the customer for additional information. Further suchadditional information may assist the incentive engine 314 to determinethe ACH cost and incentive. If the value of the incentive is lower thanthe value of the incentive associated with the rendered card, theincentive engine 314 may suggest ACH as an alternate method of payment.Persons of ordinary skill in the art understand that differences betweenthe cost of process a payment from card and the corresponding offeredincentives offered may not linear. For example, a rewards credit cardmay have a cost of $5 and offer no incentive, a conventional credit cardmay have a cost of $3 and have an incentive of a $1 discount, and adebit card may have a cost of $1 and have an incentive of a $3 discount.Such a nonlinear offering of incentives may motivate customers to chooseto render the card with the lowest cost.

It is possible that the system 300 may not suggest to render analternate card to customer because savings is too small (due to costassociated with processing the card) as compared to the initiallyrendered card (e.g. debit card). In such an embodiment, the savings arenot material in view of capturing the transaction in an efficient mannerbased on algorithm and information stored by the merchant server orFacilitator server by the incentive engine 314. For example, algorithmscould be configured such that when a value of an incentive for apossible alternate card is determined to be less than 50 cents than thevalue of the incentive of the rendered card, then the algorithmimplemented by the incentive engine 314 may prevent the incentive engine314 from suggesting such an alternate card to the customer.

Alternative embodiments may include that the system 300 in general, andincentive engine 314 in particular, to determine incentives fordifferent types of cards (e.g. rewards credit card, conventional creditcard, debit card) and suggest them to the customer after the customer isready to pay for goods and services (such as in an e-commercetransaction) but before the customer renders any card for payment.

Other embodiments may include that the BIN table 306, rate table 310,incentive table 312 are stored and associated in one or more remoteservers and are accessed by the Facilitator server 320. Furtherembodiments may include that the BIN and rate look up engines (304 and308) and/or incentive engine 314 may be implemented by an entity otherthan the Facilitator such as a financial institution, merchant, or someother third party. Additional embodiments may include that the look upengines and/or processing engine may be implemented by the clientcomputing device (e.g. POS terminal) and the BIN table, rate table andincentive table are accessible by the client computer device from aremote server (e.g. merchant server, Facilitator, and/or financialserver). Persons of ordinary skill in the art would also understand thatthe incentive software engine 314 may be a type of processing engine asshown in FIGS. 1A-1C.

However, in some embodiments, a customer may not have or may not chooseto render a conventional credit card after receiving the suggestions touse such a conventional credit card with a lower cost and hence a betterincentive (318). Thus, the customer may render another, different cardsuch as a different rewards credit card. The processing engine 303 maystore second rendered card information and calculate the card'scorresponding cost and incentive. Further, the processing engine 303 mayalso calculate alternate incentives. For example, the processing engine303, based on the algorithm may determine that when a customer renderedtwo different rewards credit cards that it may then calculate therewards credit card having the lowest cost and suggest such a rewardscredit card as an alternate to the customer. Further, the processingengine 303 may suggest the previously suggested conventional credithaving a lower cost and better incentive. The customer may then render athird card or select one of the previously rendered cards (informationfor which has been stored by the computer server) to the process acurrent transaction.

Although some embodiments disclose incentives as being goods (e.g.ringtones) or discounts (e.g. $5 off on a bill), persons of ordinaryskill in the art would understand that incentives are not limited togoods and discounts but may also include, but not be limited to,coupons, payments to charity, reward points, and third party incentivesetc. or any other type of incentive known in the art. Further, couponsinclude providing a discount on a future purchase of a good or servicefrom a merchant. Alternatively, an incentive may include providing apayment to charity by the merchant when the customer uses a card with alower cost. Moreover, an incentive may include reward points that mayinclude airline points, card points (provided by a credit card company),retail points (provided by a merchant such as a hotel chain), etc. Thirdparty incentives include, but are not limited to, one merchant offeringa coupon or discount for a good or service offered by a third partymerchant.

Referring to FIG. 3A, the exemplary functional block diagram includes aclient computing device 402, a processing engine 403, a BIN look upengine 404, a BIN table 406, rate look up engine 408, a rate table 410,a rate-incentive engine 414, and an incentive table 412. A clientcomputing device 402 may be a tablet, notebook, laptop, or desktopcomputer as well as a landline phone, mobile phone, smartphone or anyother client computing device such as a point-of-sale terminal.Alternative embodiments may have the look-up engines (404 and 408) andthe processing engine 403 on a server (e.g. merchant server, Facilitatorserver, etc.) and the client computing device 402 may have a web browseras software or be a voice or CSR terminal. The embodiment shown in FIG.3A, the processing engine 403, a BIN look up engine 404, a BIN table406, rate look up engine 408, a rate table 410, a rate-incentive engine414, and an incentive table 412 are on a Facilitator server 420. A cardholder may initiate a payment transaction by rendering a credit card ordebit card using a software application on the client computing device402. The processing engine 403 may be implemented by Facilitator server420 that receives the transaction information (e.g. card number) fromthe client computing device through a web browser, API, or other meansknown in the art and may cause the BIN look up software engine 404 andthe rate look up engine 408 to access BIN table and rate tableinformation. Further, the processing engine 403 may process thetransaction information to determine the associated cost for processingthe rendered card for the payment transaction. Note, persons of ordinaryskill in the art would understand that comparing the embodiment shown inFIGS. 3A-B with the embodiment shown in FIGS. 1A-1C, the functionalityincorporated in look up engine 204 in FIGS. 1A-1C, may be split betweenthe BIN look up engine 404 and the rate lookup engine 408 in FIGS.3A-3B.

Moreover, when the customer renders a conventional credit card, then theBIN look up engine 404 may access a BIN table 406 and rate look upengine 408 may access a rate table 310 to determine the fees associatedfor the credit card that may include the interchange fee, card networkfee, and processor fee or any other fee that may be associated with thetransaction. For example, a customer may access a utility companywebsite such a cellular phone service using a web browser on the clientcomputing device 402. The customer may render a conventional card numberto pay a cellular phone bill. The processing engine 403 receives therendered conventional credit card number and transaction informationthen passes the rendered card number to BIN look-up engine 404 and therate look-up engine 408. Further, the BIN look-up engine 404 and therate look-up engine 408 access BIN and rate information from the BINtable 406 and rate table 410, respectively. Such BIN table and ratetable information which may include the interchange fee, card networkfee, processor fee or any other applicable fee may be forwarded to therate-incentive engine 414. The BIN table 406 and rate table 410 may bestored in a database or other storage device associated with theFacilitator server 420. In addition, the rate-incentive engine 414 maycalculate the cost of processing the rendered conventional credit cardbased on such BIN and rate table information. Also, using differentalgorithms based on price elasticity, volume of card transactions,customer demand, recurring nature of the transaction or other economicfactors, the rate-incentive engine 414 may determine a convenience fee 1and incentive 1 (416) corresponding to the rendered credit conventionalcard. Alternative embodiments include that the different algorithmscalculate dynamically the convenience fee based on a discount from astatic convenience fee. The static convenience fee may be determined bythe factors mentioned above. Such incentive 1 (416) may also listed andstored in the incentive table 412 to be used in future paymenttransactions. In addition, the processing engine 403 and/or therate-incentive engine 414 may determine a convenience fee 2 andincentive 2 (418) associated with a different card (e.g. debit card)that may be more attractive to the customer and having a lower cost tothe merchant. Such an alternate card may be suggested to customerthrough a client computing device web browser, API, or other means knownin the art to the customer.

Referring to FIG. 3B, an algorithm executed by processing engine 403 maytake into account situations when a high cost card (e.g. rewards creditcard) is rendered to calculate the convenience fee of lower cost cardssuch as conventional credit cards or debit cards and also to provide abetter (i.e. increased) incentive. Consequently, the processing engine403 causes the BIN look up engine 404 and rate look up engine 408 toaccess a BIN table 406 and rate table 410, respectively, to determineBIN and rate information including the fees (e.g. interchange fee, cardnetwork fee, processor fee) associated in processing the debit card.Further, due to the requirements of the Durbin legislation, the BIN andrate information may include fees for at least two different debit cardprocessing networks. In addition, the BIN and rate information isforwarded to the rate-incentive engine 414 which determines the cost forprocessing the debit card on each network. After determining the lowercost, the incentive engine determines an incentive 2 (418) usingdifferent algorithms based on price elasticity, volume of cardtransactions, customer demand, recurring nature of the transaction orother economic factors. Typically, the cost associated with processing adebit card is lower than processing a conventional credit card. Thus,the rate-incentive engine 414 and Facilitator server 420 may suggest tothe customer to render a debit card corresponding to convenience fee 2and incentive 2 (418) instead of the conventional credit cardcorresponding to incentive 1 (416). Hence, convenience fee 2 andincentive 2 (318) may be more attractive than convenience fee 1 andincentive 1 (316) to entice a customer to render a debit card instead ofa conventional credit card. For example, convenience fee 1 may be $5 andincentive 1 (316) may allow a customer to download 10 free ringtonesfrom the cellular service provider's website. Alternatively, conveniencefee 2 may be $2 and incentive 2 (318) may allow a customer to download25 free ringtones.

In alternate embodiments, prior to offering two different conveniencefees and incentives (416 and 418), the processing engine 403 may cause aquery to the user via the web browser of the client computing device 402to request more information regarding the transaction such as PIN, cardholder address, CVV code, etc. Such additional card information may bepassed to the BIN look-up engine 404 and rate look-up engine 408 toaccess different BIN and rate information that is provided to theincentive engine 414. Further, the rate-incentive engine 414 maydetermine more attractive convenience fees and incentives (416 and 418)to suggest to the customer because, typically, the cost of processingcards is lower when more rendered information is collected from thecustomer.

Other embodiments may include that the BIN table 406, rate table 410,incentive table 412 are stored and associated in one or more remoteservers and are accessed by the Facilitator server 420. Furtherembodiments may include that the BIN and rate look up engines (404 and408) and/or incentive engine 414 may be implemented by an entity otherthan the Facilitator such as a financial institution, merchant, or someother third party. Additional embodiments may include that the look upengines and/or processing engine may be implemented by the clientcomputing device (e.g. POS terminal) and the BIN table, rate table andincentive table are accessible by the client computer device from aremote server (e.g. merchant server, Facilitator, and/or financialserver). Persons of ordinary skill in the art would also understand thatthe rate-incentive software engine 414 may be a type of processingengine as shown in FIGS. 1A-1C.

However, in some embodiments, a customer may not have or may not chooseto render a conventional credit card after receiving the suggestions touse such a conventional credit card with a lower cost and hence a betterconvenience fee-incentive (318). Thus, the customer may render another,different card such a different rewards credit card. The processingengine 403 may store second rendered card information and calculate thecard's corresponding cost and incentive. Further, the processing engine403 may also calculate alternate incentives. For example, the processingengine 403, based on the algorithm may determine that when a customerrendered two different rewards credit cards that it may then calculatethe rewards credit card having the lowest cost and suggest such arewards credit card as an alternate to the customer. Further, theprocessing engine 403 may suggest the previously suggested conventionalcredit having a lower cost and better incentive. The customer may thenrender a third card or select one of the previously rendered cards(information of which was stored by the computer server) to the processa current transaction.

Alternative embodiments with respect to the disclosure including thoseillustrated in FIGS. 1-3 may include providing alternatives orincentives to prompt the user to provide an alternate credit card or usean online payment processing system (e.g. PayPal) instead of the firstcredit card the user provided. The following examples illustrate aspectsof the present disclosure. A first example may include a merchant takingbill payments via the Internet and/or phone. The merchant may be aninsurance company qualifying the merchant for processing debit cardpayments using the EFT Network. Further, an insured uses the merchant'swebsite to pay a premium on a car policy. The insured may enter a Visacard number such that the system receives the following information:Payment Amount: $300.00; Payment Type: One Time Bill Payment; MerchantType: Insurance; and Card Number: 3456781234567890. An exemplary systemlooks up the first 6 digits of the card number in a BIN table (345678)determines that it is a debit card issued by a large financialinstitution, and that the card can be processed through the Visa Networkand the NYCE EFT Network. In addition, the exemplary system looks up thefees for a One Time Bill Payment of $300.00 through both networks anddetermines that the Visa Network results in a fee of $0.23, when the alldata is present to qualify for the lowest rate on the Visa Network,which includes an Invoice Number and the cardholder address.Alternatively, the NYCE EFT Network results in a fee of $0.70. Thesystem determines that (1) the lowest fee is achieved by processing thepayment through the Visa Network, (2) a lower fee cannot be achievedwith any other card type, (3) the Visa Network requires that thecardholder provides an address. The system also uses themerchant-specific fee tables and selects a convenience fee of $2.50.Consequently, the merchant uses this information to process the paymentthrough the Visa Network, and charge the cardholder a $2.50 conveniencefee, and prompts the cardholder for the cardholder address.

In another example, an insured may use the merchant's phone-based systemto pay a premium on a car policy. The insured may enter a Visa CardNumber and other information such that an exemplary system receives thefollowing information: Payment Amount: $300.00; Payment Type One TimeBill Payment; Merchant Type: Insurance; and Card Number:2345671234567890. Further, the exemplary system looks up the first 6digits of the card number in a BIN table (234567) and determines thatthe card is a debit card issued by a small institution and that the cardcan be processed through the Visa Network and the NYCE EFT Network. Inaddition, the exemplary system looks up the fees for a One Time BillPayment of $300.00 through both networks and determines that the NYCEEFT Network results in a cost of $0.70 and that the Visa Network resultsin a fee of $4.75. The system determines that (1) the lowest fee isachieved by processing the payment through the NYCE EFT Network, (2) alower fee cannot be achieved with any other card type, (3) the NYCE EFTNetwork does not require any additional information. The system alsouses the merchant-specific fee tables and selects a convenience fee of$2.90. The merchant uses this information to process the payment throughthe NYCE EFT Network and charge the cardholder a fee of $2.90.

In a further example, an insured uses the merchant's website to pay apremium on a car policy. The insured enters a Visa Card Number and theexemplary system receives the following information: Payment Amount:$300.00; Payment Type: One Time Bill Payment; Merchant Type: Insurance;Card Number: 1234567890123456. In addition, the exemplary system looksup the first 6 digits of the card (123456) number in a BIN table anddetermines that the card is a rewards credit card issued by a largefinancial institution, and that the card can only be processed throughthe Visa Network (card processing network). Further, the exemplarysystem looks up the fees for a One Time Bill Payment of $300.00 throughthe Visa Network results in a cost of $6.00. The system determines that(1) the lowest fee is achieved by processing the payment through theVisa Network, (2) a lower fee can be achieved with a debit card type,(3) the Visa Network does not require any additional information. Thesystem also uses the merchant-specific fee tables and selects aconvenience fee of $10.00. The merchant uses this information to offerthe cardholder a fee of $10.00, and suggests that the cardholder canlower this fee by using a debit card or an alternate credit card withoutrewards.

In an additional example, a merchant takes bill payments via theInternet. The merchant is an Internet service provider companyqualifying the merchant for processing debit card payments using the EFTNetworks. A subscriber uses the merchant's website to pay a monthlybill. Further, the subscriber enters a MasterCard Card Number. Theexemplary system receives the following information: Payment Amount:$47.50; Payment Type: One Time Bill Payment; Merchant Type InternetService Provider; Card Number: 5333331234567890. The exemplary systemlooks up the first 6 digits of the card number (533333) in a BIN tableand determines that the card is a debit card issued by a large financialinstitution and that the card can be processed through the MasterCardNetwork and the STAR EFT Network.

Thereafter, the system may lookup up the fees for a One Time BillPayment of $47.50 through both networks and determines that theMasterCard Network results in a fee of $0.23, when the all data ispresent to qualify for the lowest rate on the MasterCard Network, whichincludes an Invoice Number and the cardholder address, and that the STARNetwork results in a fee of $0.57. The system determines that (1) thelowest fee is achieved by processing the payment through the MasterCardNetwork, (2) a lower fee cannot be achieved with any other card type,(3) the MasterCard Network does not require any additional information.The system also uses the merchant-incentive tables and selects anincentive of 1 free music or game download. Consequently, the merchantuses this information to process the payment through the MasterCardNetwork and offer the cardholder a coupon for a free music or gamedownload when they make a one-time payment, or 10 free downloads whenthey setup a recurring payment.

In a further example, an Internet Service subscriber uses the merchant'swebsite pay their monthly bill. The subscriber enters a MasterCard CardNumber and the exemplary system receives the following information:Payment Amount: $47.50; Payment Type: One Time Bill Payment; MerchantType: Internet Service Provider; and Card Number: 5666661234567890. Theexemplary system looks up the first 6 digits of the card number (566666)in a BIN table and determines that card is a Rewards Credit Card issuedby a large financial, and that the card can be only processed throughthe MasterCard Network. The exemplary system lookup up the fees for aOne Time Bill Payment of $47.50 through the MasterCard Network resultsin a cost of $1.00. The system determines that (1) the lowest fee isachieved by processing the payment through the MasterCard, (2) a lowerfee can be achieved with a debit card, (3) the MasterCard Network doesnot require any additional information. The system also uses themerchant-incentive tables and selects no incentive. The merchant usesthis information to suggest to the cardholder that they can receive freegame/music downloads when they pay with a debit card rather than acredit card.

FIG. 4 is an exemplary device 500 for managing a payment transaction inaccordance with embodiments of the present disclosure. The device 500may be a computer server 505 such as the merchant computer server,Facilitator computer server, and financial institution computer server.The computer server 505 may include several different components such asa processor bank 510, storage device bank 515, one or more softwareapplications 517, and one or more communication interfaces (535-550).The processor bank 510 may include one or more processors that may beco-located with each other or may be located in different parts of thecomputer server 505. The storage device bank 515 may include one or morestorage devices. Types of storage devices may include memory devices,electronic memory, optical memory, and removable storage media. The oneor more software applications 517 may include a BIN Look up Engine 520,BIN Table 525, Rate Table 534, processing engine 530, and Rate Look upEngine 527 as well as additional software applications (not shown). Theadditional software applications may implement software functions thatassist in performing certain tasks for the computer server 505 such asproviding access to a communication network, executing an operatingsystem, managing software drivers for peripheral components, andprocessing information. Additional software applications may alsoinclude software drivers for peripheral components, user interfacecomputer programs, debugging and troubleshooting software tools.

The processing engine 530 may control and/or implement one or moresoftware applications as well as receive and transmit data from the oneor more communication interfaces (535-550). For example, the computerserver 505 may receive a credit or debit card number as well as paymenttransaction information from a client computing device or point-of-sale(POS) terminal. The processing engine 530 may receive the credit ordebit card number and payment transaction information from one of thecommunication interfaces (535-550) as well as an API and forwards suchcredit or debit card number and payment transaction information to theBIN look up engine 520. Upon receiving the credit or debit card numberand payment transaction information, the BIN look up engine discerns thebank identification number (BIN) from the first six digits of the creditor debit card and consults a BIN table 525 to determine the card type(e.g. credit, debit, prepaid, etc.), issuing financial institution forthe card, and a network for processing the card. In some embodimentsmore than one processing network may be available for a card (e.g. debitcard). Based on the card type, issuing financial institution, andprocessing network the BIN look up engine 520 may determine one or morefees for processing the rendered card and forward such fees to theprocessing engine 530. Further, based on the rendered card andtransaction information, processing engine 530 may cause the rate lookup engine 527 to consult a rate table 534 to determine additionalrates/fees for the processing the rendered card. The rate look up engine527 may forward the additional rates/fees to the processing engine 530.The fees determined from the BIN and rate table information may includethe interchange fee, card network fee, and processor fee. The processingengine 530 may determine the cost of processing the rendered card basedon the interchange fee, card network fee, and processor fee. Further,the processing engine 530 may determine a convenience fee usingdifferent algorithms based on price elasticity, volume of cardtransactions, customer demand, recurring nature of the transaction orother economic factors. Alternatively or in addition, the incentiveengine 536 may determine an incentive to the customer based on the costof the processing the rendered card using different algorithms based onprice elasticity, volume of card transactions, customer demand,recurring nature of the transaction or other economic factors.

Moreover, the cost associated in processing a debit card is typicallylower than the cost of processing a credit card. Thus, when the renderedcard was a credit card, the computer server 505 may suggest to thecustomer to use a debit card having a lower convenience fee. As aresult, the processing engine may cause the BIN look up engine 520 andrate look up engine 527 to access at least the BIN and rate tableinformation for a debit card. Further, due to the Durbin legislation,the BIN and rate table information for two different debit cardprocessing networks may be provided. The processing engine 530determines the cost of processing a debit card on the different debitcard processing networks and selects the lower cost. In addition, theprocessing engine 530 determines a convenience fee based on the cost aswell as using different algorithms based on price elasticity, volume ofcard transactions, customer demand, recurring nature of the transactionor other economic factors. Also, the incentive engine 536 may determinean incentive based on the cost of processing the debit card as well asusing different algorithms based on price elasticity, volume of cardtransactions, customer demand, recurring nature of the transaction orother economic factors. Alternative embodiments include that thedifferent algorithms calculate dynamically the convenience fee based ona discount from a static convenience fee. The static convenience fee maybe determined by the factors mentioned above. As a result, the computerserver 505 may suggest a convenience fee and/or incentive correspondingto a debit card.

In addition, prior to determining the cost of processing a renderedcard, the processing engine 530 may request then receive other card andcardholder information such as the expiration date, security code,cardholder address, or PIN as well as the merchant type and transactiontype. The processing engine may then cause the BIN look up engine 520and the rate look up engine 527 to access different BIN and rate tableinformation that provides a lower cost for processing the rendered card.

Further, the computer server 505 may include a payment service engine538 that can access a service fee table (not shown) and determine one ormore service fees based on the rendered card and transaction informationand the service fee table. The service table is generated based on oneor more bank identification tables and one or more rate tables and theservice fee table are capable of being configured by a merchant.

Each of the communication interfaces (535-550) shown in FIG. 4 may besoftware or hardware associated in communicating to other devices. Thecommunication interfaces (535-550) may be of different types thatinclude an API, a user interface, USB, Ethernet, WiFi, WiMax, wireless,optical, cellular, voice (IVR), or any other communication interfacecoupled to communication network.

An intra-device communication link 555 between the processor bank 510,storage device bank 515, software applications 517, and communicationinterfaces (535-550) may be one of several types that include a bus orother communication mechanism.

Persons of ordinary skill in the art would understand that some of thecomponents of the computer server 505 shown in FIG. 4 may be splitbetween one or more computer servers such as between a merchant serverand a Facilitator server or a financial institution server, or a subsetthereof. Further, although embodiments in the present disclosure use theBIN to be the first six digits of a rendered card number, persons ofordinary skill in the art would understand that the BIN could be more orless than 6 digits.

FIG. 5 is another exemplary device 600 for managing payment transactionfees in accordance with embodiments of the present disclosure. Thedevice 600 may be a client computing device 605 such as a POS terminal.The client computing device 605 may include several different componentssuch as a processor bank 610, storage device bank 615, one or moresoftware applications 617, and one or more communication interfaces(635-650). The processor bank 610 may include one or more processorsthat may be co-located with each other or may be located in differentparts of the client computing device 605. The storage device bank 615may include one or more storage devices. Types of storage devices mayinclude memory devices, electronic memory, optical memory, and removablestorage media. The one or more software applications 617 may include aBIN Look up Engine 320, processing engine 630, and Rate Look up Engine627 as well as additional software applications (not shown). Theadditional software applications may implement software functions thatassist in performing certain tasks for the client computing device 605such as providing access to a communication network, executing anoperating system, managing software drivers for peripheral components,and processing information. Additional software applications may alsoinclude software drivers for peripheral components, user interfacecomputer programs, debugging and troubleshooting software tools.

The processing engine 630 may control and/or implement one or moresoftware applications as well as receive and transmit data from the oneor more communication interfaces (635-650). For example, the clientcomputing device 605 may receive a credit or debit card number as wellas payment transaction information from a customer through a userinterface. The processing engine 630 may forward such credit or debitcard number and payment transaction information to the BIN look upengine 620. Upon receiving the credit or debit card number and paymenttransaction information, the BIN look up engine 620 discerns the bankidentification number (BIN) from the first six digits of the credit ordebit card and consults a BIN table to determine the card type (e.g.credit, debit, prepaid, etc.), issuing financial institution for thecard, and a network for processing the card. In some embodiments morethan one processing network may be available for a card (e.g. debitcard). Based on the card type, issuing financial institution, andprocessing network the BIN look up engine 620 may determine one or morefees for processing the rendered card and forward such fees to theprocessing engine 630. Further, based on the rendered card andtransaction information, processing engine 630 may cause the rate lookup engine 627 to consult a rate table to determine additional rates/feesfor the processing the rendered card. The rate look up engine 627 mayforward the additional rates/fees to the processing engine 630. The feesdetermined from the BIN and rate table information may include theinterchange fee, card network fee, and processor fee. The processingengine 630 may determine the cost of processing the rendered card basedon the interchange fee, card network fee, and processor fee. Further,the processing engine 630 may determine a convenience fee and/orincentive using different algorithms based on price elasticity, volumeof card transactions, customer demand, recurring nature of thetransaction or other economic factors. Alternative embodiments includethat the different algorithms calculate dynamically the convenience feebased on a discount from a static convenience fee. The staticconvenience fee may be determined by the factors mentioned above.

Moreover, the cost associated in processing a debit card is typicallylower than the cost of processing a credit card. Thus, when the renderedcard was a credit card, the client computing device 605 may suggest tothe customer to use a debit card having a lower convenience fee. As aresult, the processing engine 630 may cause the BIN look up engine 620and rate look up engine 627 to access at least the BIN and rate tableinformation for a debit card. Further, due to the Durban legislation,the BIN and rate table information for two different debit cardprocessing networks may be provided. The processing engine 630determines the cost of processing a debit card on the different debitcard processing networks and selects the lower cost. In addition, theprocessing engine 630 determines a convenience fee and incentive basedon the cost as well as using different algorithms based on priceelasticity, volume of card transactions, customer demand, recurringnature of the transaction or other economic factors. Alternativeembodiments include that the different algorithms calculate theconvenience fee or incentive based on a discount from a static cost ofprocessing the card As a result, the client computing device 605 maysuggest a convenience fee and/or incentive corresponding to a debitcard.

In addition, prior to determining the cost of processing a renderedcard, the processing engine 630 may request then receive other card andcardholder information such as the expiration date, security code,cardholder address, or PIN as well as the merchant type and transactiontype. The processing engine may then cause the BIN look up engine 620and the rate look up engine 627 to access different BIN and rate tableinformation that provides a lower cost for processing the rendered card.

Each of the communication interfaces (635-650) shown in FIG. 5 may besoftware or hardware associated in communicating to other devices. Thecommunication interfaces (635-650) may be of different types thatinclude an API, a card reader implementing Near Field Communication(NFC) protocol or some other Radio Frequency (RF) protocol or magneticstrip, a user interface, USB, Ethernet, WiFi, WiMax, wireless, optical,cellular, voice, or any other communication interface coupled tocommunication network.

An intra-device communication link 655 between the processor bank 610,storage device bank 615, software applications 617, and communicationinterfaces (635-650) may be one of several types that include a bus orother communication mechanism.

Persons of ordinary skill in the art would understand that some of thecomponents of the client computing device 605 shown in FIG. 4 may besplit between one or more computer servers such as between a merchantserver and a Facilitator server or a financial institution server, or asubset thereof.

FIG. 6 is an exemplary flowchart 700 of an example method for managingpayment transactions in accordance with embodiments of the presentdisclosure. In an example step of the example method 700, a customerinitiates a payment transaction with a merchant and renders cardinformation, as shown in block 705. The customer may initiate thetransaction using one of various client computing devices that includebut are not limited to a smartphone, mobile phone, tablet computer,notebook computer, laptop computer, desktop computer, land-linetelephone, stationary POS terminal, portable POS terminal or any otherclient device. Further, the customer renders a credit card or a debitcard to initiate the payment transaction and uses a software applicationto facilitate completion of the payment transaction such as a check-outprocedure or software program (e.g. web browser). The softwareapplication may be developed and operated by a merchant or Facilitatorto whom the customer is rendering payment or may be developed oroperated by another third party. When initiating the paymenttransaction, the customer may render relevant card information thatincludes, but is not limited to, the card number, expiration date,security code, cardholder address, PIN, transaction type, and merchanttype. An additional step in the example method 700 may be that aFacilitator server receives the card (e.g. credit card, debit card,etc.) and transaction information, as shown in block 710. TheFacilitator computer server may be as the one described in reference toFIGS. 1A-4. Further, the Facilitator computer server may verify the cardinformation by applying certain business rules (e.g. checking cardnumber length, valid number sequence, etc.). A further step in theexample method may be one or more look up software engines implementedor running on the Facilitator server access BIN and rate tables thathave fee information associated with different card processing networksfor different credit cards and debit cards, as shown in block 715.Further, the BIN and rate table information may include an interchangefee, card network fee, and processor fee.

A further step in the example method 700 may include a processing engineon the Facilitator server to determine the cost of the rendered cardbased on the interchange fee, card network fee, and processor fee, asshown in block 716. An additional step may be determining a conveniencefee and/or incentive of the rendered card by a processing engine orincentive engine residing on the Facilitator server, as shown in block717. Another step may include the processing engine determiningalternate cards that may have a lower cost to process, as shown in block720. Such a step may include the processing engine causing the look upengines to access BIN and rate table information for alternate cardsthen determining a convenience fee and/or incentive for each alternatecard. Such cards may then be suggested, provided or presented to thecustomer. These alternate cards may also be cards that are suggested tothe user to render to lower cost or convenience fee of the transactionor provide a larger incentive.

In one embodiment, the customer may initiate the payment transactionusing a credit card that incurs the card holder a convenience fee of $5.However, the processing engine analyzes the fees associated with othercredit cards and debit cards. The processing engine on the server maycause the software application on the client computing device todisplay/suggest alternate cards such as a debit card that would incuronly $1 convenience fee. Reasons for issuers, acquirers, and/or cardnetworks to charge a lower fee for debit card transactions compared tocredit card transaction is because identity of the debit card holder maybe verified at the time of the payment transaction with a personalidentification number (PIN). In another embodiment, the merchant mayabsorb the fees associated with all credit card and debit cardtransactions.

In another example, a customer for a merchant interacts with a POSterminal or telephone and renders a card for payment to purchase goodsor services. The POS terminal may interact with a merchant server or aFacilitator server to determine the transaction cost to be $4.30. Basedon a certain formulas determined by one or more algorithms implementedby a processing or some other software engine on the Facilitator server(or other server or computing device), the merchant may charge thecustomer a $7.00 convenience fee for the transaction. Such a conveniencefee may be determined between the merchant and/or the Facilitator basedon business data (e.g. volume of credit card transactions, etc.). The$2.70 difference between the $4.30 transaction fee and the $7.00convenience fee is the facilitator or merchant profit for thetransaction. The algorithms implemented by the software enginesdescribed in the present disclosure may include requesting moreinformation from the customer (e.g. zip code, etc.) or prompt thecustomer to use a different type of card (business credit card, debitcard, merchant credit card etc.) to lower the transaction fee andthereby the convenience fee (when the profit remains the same).

The embodiments of the present disclosure may be implemented inconjunction with any type of client computing device including apoint-of-sale terminal as well as a client computing device having thecapability to access a web-based bill payment software program. Suchembodiments may include an API so the software interfaces between theclient computing device and the merchant server may be abstracted sothat such interfaces and parts of the software applications/engines maybe implemented by a third party server such as a Facilitator server.

Note that the functional blocks, methods, devices and systems describedin the present disclosure may be integrated or divided into differentcombination of systems, devices, and functional blocks as would be knownto those skilled in the art.

In general, it should be understood that the circuits described hereinmay be implemented in hardware using integrated circuit developmenttechnologies, or yet via some other methods, or the combination ofhardware and software objects that could be ordered, parameterized, andconnected in a software environment to implement different functionsdescribed herein. For example, the present application may beimplemented using a general purpose or dedicated processor running asoftware application through volatile or non-volatile memory. Also, thehardware objects could communicate using electrical signals, with statesof the signals representing different data.

It should be further understood that this and other arrangementsdescribed herein are for purposes of example only. As such, thoseskilled in the art will appreciate that other arrangements and otherelements (e.g. machines, interfaces, functions, orders, and groupings offunctions, etc.) can be used instead, and some elements may be omittedaltogether according to the desired results. Further, many of theelements that are described are functional entities that may beimplemented as discrete or distributed components or in conjunction withother components, in any suitable combination and location.

The present disclosure is not to be limited in terms of the particularembodiments described in this application, which are intended asillustrations of various aspects. Many modifications and variations canbe made without departing from its spirit and scope, as will be apparentto those skilled in the art. Functionally equivalent methods andapparatuses within the scope of the disclosure, in addition to thoseenumerated herein, will be apparent to those skilled in the art from theforegoing descriptions. Such modifications and variations are intendedto fall within the scope of the appended claims. The present disclosureis to be limited only by the terms of the appended claims, along withthe full scope of equivalents to which such claims are entitled. It isto be understood that this disclosure is not limited to particularmethods, reagents, compounds compositions, or biological systems, whichcan, of course, vary. It is also to be understood that the terminologyused herein is for the purpose of describing particular embodimentsonly, and is not intended to be limiting.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art can translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations may be expressly set forth herein for sakeof clarity.

It will be understood by those within the art that, in general, termsused herein, and especially in the appended claims (e.g., bodies of theappended claims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.). It will be further understood by those within the art that when aspecific number of an introduced claim recitation is intended, such anintent will be explicitly recited in the claim, and in the absence ofsuch recitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to embodiments containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should be interpreted to mean “at least one”or “one or more”); the same holds true for the use of definite articlesused to introduce claim recitations. In addition, even when a specificnumber of an introduced claim recitation is explicitly recited, thoseskilled in the art will recognize that such recitation should beinterpreted to mean at least the recited number (e.g., the barerecitation of “two recitations,” without other modifiers, means at leasttwo recitations, or two or more recitations). Furthermore, in thoseinstances where a convention analogous to “at least one of A, B, and C,etc.” is used, in general such a construction is intended in the senseone having skill in the art would understand the convention (e.g., “asystem having at least one of A, B, and C” would include but not belimited to systems that have A alone, B alone, C alone, A and Btogether, A and C together, B and C together, and/or A, B, and Ctogether, etc.). In those instances where a convention analogous to “atleast one of A, B, or C, etc.” is used, in general such a constructionis intended in the sense one having skill in the art would understandthe convention (e.g., “a system having at least one of A, B, or C” wouldinclude but not be limited to systems that have A alone, B alone, Calone, A and B together, A and C together, B and C together, and/or A,B, and C together, etc.). It will be further understood by those withinthe art that virtually any disjunctive word and/or phrase presenting twoor more alternate terms, whether in the description, claims, ordrawings, should be understood to contemplate the possibilities ofincluding one of the terms, either of the terms, or both terms. Forexample, the phrase “A or B” will be understood to include thepossibilities of “A” or “B” or “A and B.” Furthermore, the term“convenience fee” is to be understood to include the term “surchargefee” which is a fee that a merchant charges a user for completing apayment transaction using a card.

In addition, where features or aspects of the disclosure are describedin terms of Markush groups, those skilled in the art will recognize thatthe disclosure is also thereby described in terms of any individualmember or subgroup of members of the Markush group.

As will be understood by one skilled in the art, for any and allpurposes, such as in terms of providing a written description, allranges disclosed herein also encompass any and all possible subrangesand combinations of subranges thereof. Any listed range can be easilyrecognized as sufficiently describing and enabling the same range beingbroken down into at least equal halves, thirds, quarters, fifths,tenths, etc. As a non-limiting example, each range discussed herein canbe readily broken down into a lower third, middle third and upper third,etc. As will also be understood by one skilled in the art all languagesuch as “up to,” “at least,” “greater than,” “less than,” and the likeinclude the number recited and refer to ranges which can be subsequentlybroken down into subranges as discussed above. Finally, as will beunderstood by one skilled in the art, a range includes each individualmember. Thus, for example, a group having 1-3 cells refers to groupshaving 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers togroups having 1, 2, 3, 4, or 5 cells, and so forth.

While various aspects and embodiments have been disclosed herein, otheraspects and embodiments will be apparent to those skilled in the art.The various aspects and embodiments disclosed herein are for purposes ofillustration and are not intended to be limiting, with the true scopeand spirit being indicated by the following claims.

1-14. (canceled)
 15. A method for managing a payment transaction, themethod comprising: receiving, at a processor, a transaction informationinput corresponding to a particular card; in response to receiving thetransaction information input, accessing, by the processor, a bankidentification number (BIN) table and a rate table stored in a storagedevice; calculating, by the processor, a transaction cost based on astored algorithm using the transaction information input applied fromthe BIN and rate tables; suggesting, by the processor, one or morealternate card types based on the transaction costs of each of thealternate card types using the stored algorithm; outputting one or moreincentives based on the transaction cost of each of the one or morealternate card types.
 16. The method of claim 15, further comprising:completing the payment transaction based on the transaction informationinput.
 17. The method of claim 15, wherein the transaction cost includesinterchange fees, network fees, and processor fees.
 18. The method ofclaim 15, further comprising: in response to user input of an alternatecard associated with the one or more alternate card types, completingthe payment transaction by accessing transaction.
 19. (canceled)
 20. Themethod of claim 15, wherein the transaction information input isselected from a group consisting of: payment information, a paymentamount, a transaction type, merchant information, a merchant type, amerchant category, card information, a card type, a card number, a BIN,a card expiration date, a cardholder address, a PIN, a security code,asset size of the card issuer, card networks of which the card issuer isa member, merchant category code (MCC), a cardholder name and acombination thereof.
 21. The method of claim 15, wherein the card isselected from a group consisting of: a credit card, a debit card, aprepaid card, a charge card, a reward credit card, a corporate creditcard, a corporate debit card, a rewards debit card, a retailer creditcard, a gift card, a stored value card, and a combination thereof. 22.The method of claim 15, wherein the incentive is selected from a groupconsisting of: currency, merchant incentives, goods, services, coupons,charities gifts, gift, points, third party incentives, or a combinationthereof.
 23. The method of claim 15, further comprising: accessing, bythe processor, a blocking list, wherein the blocking list is stored onthe storage device and includes a plurality of transaction informationinput; determining, by the processor, that the particular card is on theblocking list; and outputting, by the processor, a notice to a userindicating that the particular card cannot be processed.
 24. A systemfor managing a payment transaction, the system comprising: one or morenetwork interfaces to communicate with a one or more communicationnetworks and configured to receive a transaction information inputcorresponding to a particular card; one or more processors coupled tothe network interfaces and adapted to execute one or more processors;and a memory configured to store a process executable by the processor,the process when executed operable to: receive a transaction informationinput corresponding to a particular card; in response to receiving thetransaction information input, access a bank identification number (BIN)table and a rate table stored in a storage device; calculate atransaction cost based on a stored algorithm using the transactioninformation input applied from the BIN and rate tables; suggest one ormore alternate card types based on the transaction costs of each of thealternate card types using the stored algorithm; output one or moreincentives based on the transaction cost of each of the one or morealternate card types.
 25. The system of claim 24, wherein the processwhen executed is further operable to: complete the payment transactionbased on the transaction information input.
 26. The method of claim 24,wherein the incentive is determined using an implemented algorithm usingat least the transaction processing cost.
 27. The method of claim 24,wherein the transaction cost includes interchange fees, network fees,and processor fees.
 28. The method of claim 24, wherein the process whenexecuted is further operable to: compare a calculated cost and alternatecosts corresponding to alternate card types using the BIN and ratetables; determine suggested card types having a lower calculated costthan the calculated cost; output the suggested card types and thecorresponding incentives; and complete the payment transaction by usingthe transaction information input of the user selected card type. 29.The system of claim 24, wherein the process when executed is furtheroperable to: in response to user input of an alternate card associatedwith the one or more alternate card types, completing the paymenttransaction.
 30. The system of claim 24, wherein the transactioninformation input is selected from a group consisting of: paymentinformation, a payment amount, a transaction type, merchant information,a merchant type, a merchant category, card information, a card type, acard number, a BIN, a card expiration date, a cardholder address, a PIN,a security code, asset size of the card issuer, card networks of whichthe card issuer is a member, merchant category code (MCC), a cardholdername and a combination thereof.
 31. The system of claim 23, wherein thecard is selected from a group consisting of: a credit card, a debitcard, a prepaid card, a charge card, a reward credit card, a corporatecredit card, a corporate debit card, a rewards debit card, a retailercredit card, a gift card, a stored value card, and a combinationthereof.
 32. The system of claim 23, wherein the incentive is selectedfrom a group consisting of: currency, merchant incentives, goods,services, coupons, charities gifts, gift, points, third partyincentives, or a combination thereof.
 33. The system of claim 23,wherein the process when executed is further operable to: access ablocking list, wherein the blocking list is stored on the storage deviceand includes a plurality of transaction information input; determinethat the particular card is on the blocking list; and output a notice toa user indicating that the particular card cannot be processed.
 34. Amethod for managing a payment transaction, the method comprising:receiving, at a processor, transaction information input correspondingto a particular card; in response to receiving the transactioninformation input, accessing, by the processor, a bank identificationnumber (BIN) table and a rate table stored in a storage device;calculating, by the processor, a transaction cost based on a storedalgorithm that utilizes at least the transaction information input, theBIN table and the rate table; comparing, by the processor, thecalculated transaction cost to transactions costs of an automatedclearing house (ACH) transaction for the payment transaction; inresponse to the ACH cost being lower than the transaction costassociated with the particular card, outputting an incentive toalternately use the payment as the ACH transaction.
 35. The method ofclaim 34, further comprising: completing the payment transaction basedon the transaction information input or the ACH transaction.
 36. Themethod of claim 34, wherein the transaction information input isselected from a group consisting of: payment information, a paymentamount, a transaction type, merchant information, a merchant type, amerchant category, card information, a card type, a card number, a BIN,a card expiration date, a cardholder address, a PIN, a security code,asset size of the card issuer, card networks of which the card issuer isa member, merchant category code (MCC), a cardholder name and acombination thereof.
 37. The method of claim 34, wherein the card isselected from a group consisting of: a credit card, a debit card, aprepaid card, a charge card, a reward credit card, a corporate creditcard, a corporate debit card, a rewards debit card, a retailer creditcard, a gift card, a stored value card, and a combination thereof. 38.The method of claim 34, wherein the incentive is selected from a groupconsisting of: currency, merchant incentives, goods, services, coupons,charities gifts, gift, points, third party incentives, or a combinationthereof.
 39. The method of claim 15, further comprising: receiving morethan one transaction information input, in response to the receivingmore than one card type, determining incentives for each of the cardtypes.
 40. The method of claim 39, further comprising: completing thepayment transaction based on the transaction information input.
 41. Thesystem of claim 23, further comprising: receiving more than onetransaction information input, in response to the receiving more thanone card type, determining incentives for each of the card types. 42.The system of claim 41, further comprising: completing the paymenttransaction based on the transaction information input.
 43. The methodof claim 15, wherein the stored algorithm calculates the incentive forrecurring the payment transaction.
 44. The method of claim 34, whereinthe stored algorithm calculates the incentive for recurring the paymenttransaction.
 45. The system of claim 24, wherein the stored algorithmcalculates the incentive for recurring the payment transaction.